The  Golden  Age  of  Software  Arehiteeture: 
A  Comprehensive  Survey 

Mary  Shaw  and  Paul  Clements* 


February  2006 
CMU-ISRI-06-101 


Institute  for  Software  Researeh  International 
Sehool  of  Computer  Seienee 
5000  Forbes  Avenue 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Abstract 

This  retrospeetive  on  nearly  two  deeades  of  software  arehiteeture  researeh  examines 
the  maturation  of  the  software  arehiteeture  researeh  area  by  traeing  the  evolution  of 
researeh  questions  and  results  through  their  maturation  eyele.  We  show  how  early 
qualitative  results  set  the  stage  for  later  preeision,  formality,  and  automation,  how 
results  have  built  up  over  time,  and  how  the  researeh  results  have  moved  into 
praetiee. 


*  Software  Engineering  Institute,  Carnegie  Mellon  University,  Pittsburgh  PA  15213 

Mary  Shaw’s  work  is  supported  by  the  Software  Industry  Center,  the  AJ.  Perils  Chair  of  Computer 
Science,  and  the  National  Science  Foundation  under  Grant  CCF-0438929.  The  Software  Engineering 
Institute  is  sponsored  by  the  U.S.  Department  of  Defense.  The  views  and  conclusions  contained  in 
this  document  are  those  of  the  authors  and  do  not  necessarily  reflect  the  opinions  of  the  sponsoring 
organizations. 


Report  Documentation  Page 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 


1.  REPORT  DATE 

FEB  2006 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2006  to  00-00-2006 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


4.  TITLE  AND  SUBTITLE 

The  Golden  Age  of  Software  Architecture:  A  Comprehensive  Survey 


6.  AUTHOR(S) 


7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Carnegie  Mellon  University, School  of  Computer  Science, Institute  for  report  number 

Software  Research  International, Pittsburgh, PA, 15213 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES)  10.  SPONSOR/MONITOR’S  ACRONYM(S) 

II.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

This  retrospective  on  nearly  two  decades  of  software  architecture  research  examines  the  maturation  of  the 
software  architecture  research  area  by  tracing  the  evolution  of  research  questions  and  results  through 
their  maturation  cycle.  We  show  how  early  qualitative  results  set  the  stage  for  later  precision,  formality, 
and  automation,  how  results  have  built  up  over  time,  and  how  the  research  results  have  moved  into 
practice. 

15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

18.  NUMBER 

19a.  NAME  OE 

ABSTRACT 

OF  PAGES 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Same  as 
Report  (SAR) 

14 

Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


Keywords:  Software  architecture,  technology  maturation,  history  of  software 
engineering 


The  Golden  Age  of  Software  Architecture:  A  Comprehensive  Survey  * 


Mary  Shaw 

Institute  for  Software  Research,  International 
Carnegie  Mellon  University 
Pittsburgh  PA  15213  USA 

mary.shaw@cs.cmu.edu 

Abstract 

This  retrospective  on  nearly  two  decades  of  software 
architecture  research  examines  the  maturation  of  the 
software  architecture  research  area  by  tracing  the 
evolution  of  research  questions  and  results  through  their 
maturation  cycle.  We  show  how  early  qualitative  results 
set  the  stage  for  later  precision,  formality,  and  automation, 
how  results  have  built  up  over  time,  and  how  the  research 
results  have  moved  into  practice. 
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1.  Introduction 

Since  the  late  1980’s,  software  architecture  research 
has  emerged  as  the  principled  study  of  the  large-scale 
structures  of  software  systems.  From  its  roots  in 
qualitative  descriptions  of  empirically  observed  useful 
system  organizations,  software  architecture  has  matured  to 
encompass  broad  explorations  of  notations,  tools,  and 
analysis  techniques.  Whereas  initially  the  research  area 
interpreted  software  practice,  it  now  offers  concrete 
guidance  for  complex  software  design  and  development. 
It  has  made  the  transition  from  basic  research  to  an 
essential  element  of  software  system  design  and 
construction. 

This  retrospective  examines  the  trajectory  software 
architecture  has  taken  in  the  context  of  a  technology 
maturation  model,  matching  significant  accomplishments 
in  software  architecture  to  the  stages  of  that  model  to  gain 
perspective  on  where  the  field  stands  today. 

This  trajectory  has  taken  software  architecture  to  its 
“golden  age”  and  that  in  the  near  future  it  will  attain  the 
status  of  all  truly  successful  technologies:  It  will  be 
considered  an  unexceptional  and  essential  part  of  software 
system  building,  taken  for  granted,  employed  without 
fanfare,  and  assumed  as  a  natural  base  for  further 
progress. 

*  This  paper  updates  an  invited  keynote  for  ICSE  23,  “The 
Coming-of-Age  of  Software  Architecture  Research”  by  Mary 
Shaw[77].  It  is  also  the  basis  for  “The  Golden  Age  of  Software 
Architecture  ”  published  in  IEEE  Software,  March/April  2006 
[79]. 


Paul  Clements 
Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213  USA 

olements@sei.omu.edu 

2,  How  Technologies  Mature 

Redwine  and  Riddle  [71]  reviewed  several  software 
technologies  to  see  how  they  develop  and  propagate.  They 
found  it  typically  takes  15-20  years  for  a  technology  to 
enter  widespread  use.  They  identified  six  typical  phases: 

•  Basic  research.  Investigate  basic  ideas  and  concepts, 
put  initial  structure  on  the  problem,  frame  critical 
research  questions. 

•  Concept  formulation.  Circulate  ideas  informally, 
develop  a  research  community,  converge  on  a 
compatible  set  of  ideas,  solve  specific  subproblems, 
refine  the  structure  of  the  problem. 

•  Development  and  extension.  Explore  preliminary 
applications  of  the  technology,  clarify  underlying 
ideas,  generalize  the  approach. 

•  Internal  enhancement  and  exploration.  Extend 
approach  to  other  domains,  use  technology  for  real 
problems,  stabilize  technology,  develop  training 
materials,  show  value  in  results. 

•  External  enhancement  and  exploration.  Similar  to 
internal,  but  involving  a  broader  community  of  people 
who  weren’t  developers,  show  substantial  evidence  of 
value  and  applicability.  Flesh  out  the  details  to 
provide  a  complete  system  solution. 

•  Popularization.  Develop  production-quality, 
supported  versions  of  the  technology,  commercialize 
and  market  technology,  expand  user  community 

As  technologies  mature,  their  institutional 
mechanisms  for  disseminating  results  also  change.  These 
mechanisms  begin  with  informal  discussions  among 
colleagues  and  progress  to  products  in  the  marketplace. 
Along  the  way,  preliminary  results  of  the  first  two  phases 
appear  in  position  papers,  workshops,  and  research 
conferences.  As  the  ideas  mature,  results  appear  in 
conferences  and  then  journals;  larger  conferences  set  up 
tracks  featuring  the  technology,  and  eventually  richer 
streams  of  results  may  justify  topical  conferences.  Books 
that  synthesize  multiple  results  help  to  move  the 
technology  through  the  exploration  phases.  University 
courses,  continuing  education  courses,  and  standards 
indicate  the  beginning  of  popularization. 
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3.  Maturation  of  software  architecture 

Software  architecture  is  the  principled  study  of  the 
large-scale  structures  of  software  systems.  From  its  roots 
in  qualitative  descriptions  of  useful  system  organizations, 
software  architecture  has  matured  to  encompass  broad  ex¬ 
plorations  of  notations,  tools,  analysis  techniques,  and 
creation  methods.  Whereas  initially  the  research  area 
interpreted  software  practice,  it  now  offers  concrete 
guidance  for  complex  software  design  and  development. 

Software  architecture  overlaps  and  interacts  with  the 
study  of  software  families,  domain-specific  design, 
component-based  reuse,  software  design,  specific  classes 
of  components,  and  program  analysis.  It  is  not  productive 
to  attempt  rigid  separation  among  these  areas;  research 
can  certainly  contribute  to  more  than  one. 

One  way  to  see  the  growth  of  the  field  is  to  examine 
the  rate  at  which  earlier  results  serve  as  building  blocks 
for  subsequent  results.  A  rough  estimate  is  provided  by 
citation  counts  for  papers  with  “software  architecture”  in 
the  title.  Virtually  all  of  the  cited  papers  were  published  in 
1990  or  later.  There  were  steady  increases  in  the  number 
of  citations  of  papers  published  from  1991  to  1996  and  a 
sharp  increase  for  papers  published  in  1998.  The  two 
dozen  most  widely-cited  books  and  papers  were  published 
between  1991  and  2000.  They  include  five  books 
([12][17][72][82][94],  1995  to  2000),  four  papers 

presenting  surveys  or  models  for  the  field  ([33][34][57] 
[68],  1992  to  1997),  six  papers  dealing  with  architecture 
for  particular  domains  ([18][19][24][27][51][53],  1991  to 
1998),  seven  formalizations  ([1][2][3][43][54][55][62], 
1992  to  1996),  and  one  paper  each  on  an  architectural 
description  language  [80]  and  an  analysis  technique  [46]. 
The  major  changes  in  this  pattern  since  a  similar  count  in 
2001  [77]  are  an  increase  in  citations  of  formalizations 
and  substantial  turnover  in  the  most-cited  papers  about 
architectures  for  specific  domains. 

This  indicator  is  based  on  the  published  literature,  so 
it  naturally  reflects  the  first  three  phases  of  development. 
Imperfect  though  this  estimate  may  be,  it  still  indicates 
very  substantial  growth  over  the  past  decade  or  so  and  a 
balance  between  exploration  of  specific  problems  and 
development  of  generalizations  and  formalizations.  Of  the 
two  dozen  papers  that  were  most  commonly  cited  in  2001, 
fourteen  remain  among  the  most  commonly  cited  papers 
in  2005  -  an  indication  that  the  seminal  sources  have  been 
identified.  The  Appendix  compares  the  lists  from  2001 
and  2005. 

Here  are  some  of  the  highlights  of  the  field’s 
development,  mapped  to  the  Redwine/Riddle  model.  The 
chronology  is  not  as  linear  as  the  Redwine/Riddle  model 
might  suggest:  different  aspects  of  the  field  evolve  at 


different  rates;  transitions  between  phases  do  not  happen 
instantly;  and  publication  dates  lag  the  actual  work  by 
different  amounts,  as  indicated  in  the  figure  Nevertheless, 
overall  progress  corresponds  fairly  well  to  their  model. 

3.1  Basic  research  phase:  1985-1994* 

For  as  long  as  complex  software  systems  have  been 
developed,  designers  have  described  their  structures  with 
box-and-line  diagrams  and  informal  explanations.  Good 
designers  recognized  stylistic  commonalities  among  these 
structures  and  exploited  the  styles  in  ad  hoc  ways.  These 
structures  were  sometimes  called  architectures,  but  knowl¬ 
edge  about  common  styles  -generally  useful  structural 
forms  -  was  not  systematically  organized  or  taught. 

Significantly,  by  the  mid-1980s  several  foundational 
ideas  were  firmly  in  place,  having  traveled  their  own  15- 
20-year  Redwine-Riddle  cycles.  These  included 
information-hiding,  abstract  data  types,  and  other  ideas 
that  contributed  to  considering  software  elements  as  black 
boxes.  Object-oriented  development  was  building  on 
abstract  data  types  and  inheritance.  These  ideas  all  had 
their  foundations  on  observations,  for  example  by  Dijkstra 
[26]  and  Pamas  [64],  that  it  was  not  enough  for  a 
computer  program  to  produce  the  correct  outcome.  Other 
qualities  of  the  software,  such  as  dependability  and 
maintainability,  were  also  important  and  could  be 
achieved  by  careful  structuring. 

In  the  late  1980s  people  began  to  explore  the 
advantages  of  deliberately-designed  specialized  software 
structures  for  specific  problems.  Some  of  this  work 
addressed  software  system  structures  for  particular 
product  lines  or  application  domains  such  as  avionics 
[66],  oscilloscopes  [25]  and  missile  control  [22]  [60]. 

Other  work  organized  the  informal  knowledge  about 
common  formations  of  software  structures,  or 
architectural  styles,  that  can  be  used  in  a  variety  of 
problem  domains.  This  work  cataloged  existing  systems  to 
identify  common  architectural  styles  such  as  pipe-filter, 
repository,  implicit  invocation,  and  cooperating  processes, 
both  by  identifying  the  architectures  of  specific  classes  of 
systems  [7][63]  and  by  finding  general  ways  to  describe 
such  structures  [4][74][75][76].  These  complementary 
lines  of  research  led  to  models  for  explaining  the 
architectural  styles  and  to  two  widely  cited  papers  in  1992 
and  1993  that  established  the  structure  (and  settled  the 
name)  of  the  field  [34][68]. 


'  Time  spans  for  phases  are  suggested  by  the  dates  of  the  cited 
work  in  the  corresponding  section,  discounting  foundational 
works  from  the  1960s  and  1970s. 
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Foundations:  Information  hiding,  abstract  data  Types,  Importance  of  structure  to  achieve  qualities 


Basic  research 


System  stnjctures  for  specific 
problems,  catalogs  of  style 


Early  formalization  and  classification, 
Concept  formulatiog  architecture  description  languages, 

views,  a  rchitectu  re  evaluati  on,  workshops 


Develo  pment/extensi  on 


Acme,  taxonomies, 
joumais,  and  conferences 


Architectural-pattern  design  guides, 
formal  analysis,  tactics,  books,  linking 
architecture  to  quality  attributes 


Internal  enhancement/ exploration 


+ 


UML  Rational  Unified  Process,  object-oriented 
frameworks,  buiit-in  infrastructure, 
component-based  software  engineering, 
company-specific  lifecycle  models 


External  enhancement/exploration 

_ L 


Production-quality  supported  commercialized  versions  oftechnology, 

standards,  university  and  industry  courses,  attention  to  role  of  architect.  Popularization 

professional  organizations 


1985 


1990 


1995 


2000 


2005 


Figure  1.  Maturation  of  the  software  architecture  field. 


Figure  ©  2006  IEEE  [79] 


3.2  Concept  formulation  phase:  1992-1996 

The  basic  models  were  elaborated  and  explored 
largely  through  work  in  architecture  description 
languages,  early  formalization,  and  classification.  The 
early  ideas  centered  on  the  system  structures  that 
commonly  occurred  in  software  systems,  and  the  results 
emphasized  description  of  organizations  found  in  practice 
[34], 

Architecture  description  languages  [57]  served  as  a 
vehicle  to  flesh  out  specific  details  of  a  variety  of  aspects 
of  architecture.  The  early  ideas  centered  on  the  system 
structures  that  commonly  occurred  in  software  systems, 
and  the  results  emphasized  description  of  organizations 
found  in  practice  [34].  Ideas  about  system  organization, 
especially  alternatives  to  the  then-emerging  object 
orientation,  were  elaborated  in  programming  languages. 
These  languages  included  Aesop  [30]  (exploiting  specific 
properties  of  styles),  C2  [56]  (exploring  power  of  a 
particular  event-based  style),  Darwin  [54]  (design  and 
specification  of  dynamic  distributed  systems),  Meta-H 
[13]  (real-time  avionics  control),  Rapide  [52]  (simulation 
and  analysis  of  dynamic  behavior),  UniCon  [80] 
(extensible  set  of  connectors  and  styles,  compilation  to 
code),  and  Wright  [4]  (component  interaction). 


Formalizations  developed  in  parallel  with  the 
language  development.  Sometimes  this  was  integral  to  the 
language  (Darwin  [55],  Rapide,  Wright  [3]),  and  in  other 
cases  it  was  more  independent,  as  the  formalization  of 
style  [1][2]  or  formal  analysis  of  a  specific  architectural 
model  [91][43]  or  application  area  [51][53].  The 
recognition  that  multiple  views  must  be  reconciled  in 
architectural  analysis  [48]  helped  to  frame  the 
requirements  for  formalism. 

The  early  narrative  catalogs  of  styles  were  expanded 
in  taxonomies  of  styles  [78]  and  of  the  elements  that 
support  those  styles  [47].  The  common  forms  were 
cataloged  and  explained  as  patterns  [17][72].  An  early 
book  [82]  on  these  ideas  set  the  stage  for  further 
development. 

Understanding  of  the  relationship  between 
architectural  decisions  and  a  system’s  quality  attributes 
revealed  software  architecture  validation  as  a  useful  risk- 
reduction  strategy.  Interconnectivity  metrics  [73], 
checklists  for  architects  [8],  and  attribute-specific 
architecture  analysis  techniques  [84]  gave  way  to  more 
general  architecture  evaluation  methods  such  as  the 
Software  Architecture  Analysis  Method  (SAAM)  [46]. 
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Significant  in  this  phase  was  the  emergence  of 
architectural  views  as  a  working  concept.  Pamas  set  the 
stage  for  this  in  1974  [65]  with  his  observation  that 
software  systems  have  many  structures  that  serve  different 
engineering  purposes  and  it  makes  little  sense  to  call  out 
any  one  as  distinguished.  After  percolating  for  a  Redwine- 
Riddle  maturation  period,  the  concept  flowered  in 
influential  papers  [90][48][68]  that  firmly  established 
views  in  architectural  practice. 

Workshops  on  other  topics  (such  as  the  International 
Workshop  on  Software  Specification  and  Design) 
provided  a  temporary  home  for  the  software  architecture 
community.  A  formative  Dagstuhl  seminar  held  in  1995 
[32]  gathered  researchers  to  think  about  the  layout  and 
future  directions  of  the  field.  A  series  of  International 
Software  Architecture  Workshops  (associated  with  other 
conferences)  from  1995  to  2000  provided  a  welcome  and 
ongoing  forum  devoted  solely  to  software  architecture. 

3.3  Development  and  extension  phase:  1995-2000 

During  this  phase,  the  focus  shifted  to  unifying  and 
refining  initial  results.  The  Acme  architectural  interchange 
language  began  with  the  goal  of  providing  a  framework  to 
move  information  between  architecture  description 
languages  [31];  it  later  grew  to  integrate  other  design, 
analysis  and  development  tools. 

Refinement  of  the  taxonomies  of  architectural 
elements  [59]  and  languages  [58]  also  continued. 

The  institutions  of  the  area  also  matured.  The  IEEE’s 
Transactions  on  Software  Engineering  had  a  special  issue 
on  software  architecture  in  1995[33].  The  special  “road¬ 
map”  track  at  the  ICSE  2000  conference  included 
software  architecture  [29]  among  its  topics  to  survey,  and 
it  is  now  routine  for  ICSE  to  have  one  or  more  sessions  on 
architectural  topics.  A  standalone  conference,  the 
Working  lEEE/IFIP  Conference  on  Software  Architecture 
(WICSA)  began  in  1998  and  continues  to  the  present  [95]. 
One  of  its  sponsors  is  a  new  IFIP  working  group  on 
software  architecture  [41]. 

3.4  Internal  enhancement  and  exploration  phase: 
1996-2003 

Architectural  styles  (which  during  this  stage  shifted 
their  name  to  architectural  patterns  to  acknowledge  their 
kinship  with  design  patterns)  are  commonly  used 
informally  as  design  guides.  The  explicit  attention  to  this 
aspect  of  design  is  increasing,  and  as  a  result  we  are 
gaining  experience. 

A  few  formal  analyses  of  real  system  designs  have 
been  done  as  well.  For  example,  architectural 
specification  of  the  High-Level  Architecture  for 
Distributed  Simulation  [5]  was  able  to  identify 


inconsistencies  before  implementation,  thereby  saving 
extensive  redesign. 

Architectural  analysis  and  evaluation  emerged  as  a 
fertile  sub-topic.  At  the  SEI,  the  Software  Architecture 
Analysis  Method  [46]  gave  way  to  the  Architecture 
Tradeoff  Analysis  Method  (ATAM)  [45],  which  supports 
analysis  of  the  interaction  among  quality  attributes  as  well 
as  the  attributes  themselves.  Books  on  the  application  of 
the  research  to  practice  [12]  [3  6]  set  the  stage  for  external 
exploration.  Books  on  specialized  parts  of  the  practice 
such  as  architecture  evaluation  [21]  and  documentation 
[20]  also  emerged,  signaling  a  new  kind  of  maturation  of 
the  overall  field. 

Another  internal  enhancement  of  note  was  the 
exploration  of  architectural  tactics  [9],  which  are  fine¬ 
grained  architectural  design  decisions  that  contribute  to 
architectural  patterns.  During  this  stage,  the  importance  of 
quality  attributes  increased,  along  with  architecture’s  role 
in  achieving  them  [11].  The  early  2000’s  saw  work 
strongly  connecting  quality  attributes  and  architectural 
design  decisions,  and  for  the  first  time  an  automated 
architectural  design  aid  seemed  within  reach  [10]. 

3.5  External  enhancement  and  exploration 
phase:  1998-present 

Several  areas  have  matured  enough  to  be  useful 
outside  their  developer  groups. 

UML  [14],  under  the  leadership  of  (at  the  time) 
Rational,  has  integrated  a  number  of  design  notations  and 
developed  a  method  for  applying  them  systematically. 
UML  has,  for  better  or  (many  would  say)  for  worse, 
become  the  industry  standard  ADL.  Tied  inextricably  to 
UML  is  the  Rational  Unified  Process,  a  tool-centered 
industrialization  of  Kmchten’s  original  elegant  idea  of 
4-1-1  views  [48].  For  the  most  part,  UML  provides 
graphical  notations;  it  remains,  however,  to  provide  a 
robust  suite  of  tools  for  analysis,  consistency  checking,  or 
other  means  of  automatically  connecting  the  information 
expressed  in  UML  with  the  code  of  the  system. 

The  rise  of  object-oriented  software  frameworks 
provided  a  rich  development  setting  for  object-style 
architecture  and  considerable  public  enthusiasm  for 
object-orientedness.  The  benefits  of  the  built-in 
infrastructure  and  available,  interoperable  components 
provided  substantial  incentive  to  use  the  frameworks  even 
when  they  were  not  ideal  fits  for  the  problems.  These 
satisfied  needs  for  those  architectures.  As  a  result,  work 
on  general-purpose  architecture  description  languages 
gave  way  to  extensive  support  for  specific  architectures. 
At  about  the  same  time,  architecture  provided  a  solid 
enough  foundation  on  which  to  implicitly  base  the 
component-based  software  engineering  movement  [92]. 
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Also  indicative  of  external  enhancement  are 
company-specific  end-to-end  architecture -based 
development  lifecycle  models,  such  as  the  Raytheon 
Enterprise  Architecture  Process  (REAP)  [69]. 

3.6  Popularization  phase:  2000-present 

The  popularization  phase  is  characterized  by 
production-quality,  supported,  commercialized,  and 
marketed  versions  of  the  technology,  along  with  an 
expanded  user  community. 

Architectural  patterns,  fueled  in  part  by  the  explosion  of 
the  World  Wide  Web  and  web-based  e-commerce,  are 
leading  the  commercialization  wave.  N-tier  client-server 
architectures,  agent-based  architectures,  and  Service- 
Oriented  Architectures  -  along  with  the  interfaces, 
specification  languages,  tools  and  development 
environments,  and  wholly  implemented  components, 
layers,  or  subsystems  to  go  along  with  them  -  are 
examples  of  enormously  successful  architectural  patterns 
that  have  entered  everyone’s  vocabulary.  Microsoft  says 
its  .NET  platform  “includes  everything  a  business  needs 
to  develop  and  deploy  a  Web  service-connected  IT 
architecture:  servers  to  host  Web  services,  development 
tools  to  create  them,  applications  to  use  them,  and  a 
worldwide  network  of  more  than  35,000  Microsoft 
Certified  Partner  organizations  to  provide  any  help  you 
need.”[61]  Connected  services,  tools,  applications, 
platforms,  and  an  army  of  vendors,  all  built  around  an 
architecture:  This  is  true  popularization. 

One  of  the  hallmarks  of  a  production-ready  technol¬ 
ogy  is  good  standards.  Standards  for  particular  component 
families  (e.g.,  COM,  CORBA)  and  interfaces  (e.g.,  XML) 
have  existed  for  several  years,  but  they  reflect  component 
reuse  interests  as  much  as  architectural  interests.  An 
ANSI/IEEE  standard  [39]  has  attempted  to  codify  the 
current  best  practices  and  insights  of  both  the  systems  and 
software  engineering  communities  in  the  area  of 
documentation.  Newer  standards  are  emerging  all  the 
time,  primarily  in  support  of  the  important  patterns 
mentioned  above.  Recently  AADL  (a  tme  architecture 
description  language)  was  standardized  by  the  Society  of 
Automotive  Engineers  (SAE)[86]. 

One  sure  sign  of  an  expanded  user  community  is  the 
degree  to  which  people  take  ownership  of  the  terms  and 
concepts.  Bill  Gates,  who  could  have  any  title  he  chooses, 
is  Microsoft’s  “chief  software  architecf’.  The  OMG  chose 
to  call  its  development  initiative  separating  business  and 
application  logic  from  platform  technology  “model  driven 
architecture.”  The  SEI  invites  people  to  submit  their 
working  definitions  of  “software  architecture,”  and  by  late 
2005,  over  156  definitions  had  been  submitted  by 
practitioners  in  24  countries  [87].  Another  sign  is  the  way 


the  term  gets  co-opted  and  diluted  by  people  pulling  their 
own  interests  under  the  currently  popular  umbrella.  Terms 
such  as  “program  architecture”  make  us  shudder. 

An  institutional  indicator  of  popularization  is  the 
degree  to  which  the  subject  is  routinely  taught.  In 
universities,  software  architecture  is  moving  from 
graduate  to  undergraduate  curricula;  more  than  one 
textbook  for  introductory  software  engineering  courses 
now  includes  a  chapter  on  “architectural  design”  [70][93]. 
In  the  ACM/IEEE  undergraduate  software  engineering 
curriculum  [44],  20%  of  the  software  design  unit  is 
devoted  to  software  architecture.  The  Software 
Engineering  Body  of  Knowledge  identifies  software 
architecture  as  a  major  section  in  the  software  design 
chapter  [38].  Industrial  courses  and  certificate  programs 
are  also  widely  available  (e.g.,  [88],  [16],  [37],  [42]). 

Finally,  “software  architect”  is  a  job  title  that  one 
would  expect  to  find  in  any  company  that  builds  software¬ 
intensive  systems,  and  professional  organizations  such  as 
the  Worldwide  Institute  of  Software  Architects  [96]  and 
the  International  Association  of  Software  Architects  [40] 
allow  communication,  foster  networking,  encourage 
professional  practice,  and  (one  hopes)  help  their  members 
sort  out  the  avalanche  of  books  -  over  50  -  now  available 
on  the  topic. 

Conferences  continue  to  thrive,  not  only  for  the 
research  community  but  for  user  networks.  In  late  2005, 
the  SEI  listed  25  upcoming  conferences  explicitly  listing 
“software  architecture”  in  their  calls  for  participation[89]. 
These  include  user  network  meetings  as  well  as  research 
conferences. 

4,  Current  status 

It  is  fair  to  say  that  the  broad  concept  of  software 
architecture  has  run  the  full  course  of  the  Redwine-Riddle 
model,  pretty  much  right  on  schedule.  The  result  is  a 
breathtaking  capability  for  reliably  designing  systems  of 
unprecedented  size  and  complexity  verging  on  a  true 
engineering  discipline.  Consider  the  resources  readily 
available  to  a  contemporary  software  architect: 

•  Off-the-shelf  industrial  training  and  certification 
programs  that  reflect  a  converging  sense  of  what 
software  architecture  is  and  why  it  is  a  critical 
discipline 

•  Standard  architectures  for  countless  domains  and 
applications.  For  example,  nobody  will  ever  again 
have  to  design  from  scratch  a  banking  system,  an 
avionics  system,  a  satellite  ground  system,  a  web- 
based  e-commerce  system,  or  a  host  of  other  varieties 
of  systems. 
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•  Where  total  architectural  solutions  do  not  yet  exist, 
partial  ones  certainly  do  in  the  form  of  catalogs  of 
architectural  patterns  and  tactics  that  have  been  used 
to  solve  a  myriad  of  problems,  many  of  which  involve 
the  achievement  of  quality  attributes. 

•  End-to-end  lifecycle  models  (industry-wide  or,  more 
likely,  company-specific)  that  are  centered  on 
architectural  principles. 

•  Robust  and  repeatable  approaches  to  architecture 
evaluation  and  validation 

•  Practical  approaches  to  architecture  documentation, 
supported  by  standards  for  artifacts  and  standards  for 
languages  in  which  to  render  the  artifacts. 

•  Robust  tool  environments  to  capture  designs 

•  Commercial-quality  architectural  infrastructure 
layers  to  handle  inter-component  communication  and 
coordination  distributed  generic  computing 
environments 

•  Commercial-quality  application  layers  (and  tooling) 
to  handle  business  logic,  user  interface,  and  support 
function  layers 

•  Career  tracks  and  professional  societies  for  software 
architects. 

•  An  active  pipeline  of  journals  and  conferences 
devoted  to  software  architecture,  serving  as  a  conduit 
between  research  and  practice  communities. 

These  and  other  indicators  indicate  that  software 
architecture  is  integrated  in  the  fabric  of  software 
engineering. 

5,  What’s  next? 

Software  engineering  research  is  often  motivated  by 
problems  that  arise  in  the  production  and  use  of  real-world 
software.  Technical  ideas  often  begin  as  qualitative 
descriptions  of  problems  or  practice  and  gradually  become 
more  precise  -  and  more  powerful  -  as  practical  and 
formal  knowledge  grow  in  tandem.  Thus,  as  some  aspect 
of  software  development  comes  to  be  better  understood, 
more  powerful  specification  mechanisms  become  viable, 
and  this  in  turn  enables  more  powerful  technology. 

We  see  that  software  architecture  has  followed  this 
approach,  growing  from  its  adolescence  in  research 
laboratories  to  the  responsibilities  of  maturity.  This  brings 
with  it  additional  responsibility  for  researchers  to  show 
not  just  that  new  ideas  are  promising  (a  sufficient  grounds 
to  continue  research)  but  also  that  they  are  effective  (a 
necessary  grounds  to  move  into  practice). 

As  a  result,  software  architecture  researchers  must  not 
be  content  with  simply  doing  more  research  in  the  style  of 
the  past  decade.  Certainly  there  are  new  ideas  yet  to  be 


explored  in  that  form,  but  the  last  decade  has  opened  even 
more  opportunities  in  the  form  of  research  to  make 
existing  results  more  robust,  more  rigorously  understood, 
and  more  ready  to  move  into  application.  For  example, 
there  was  a  time  when  it  seemed  that  a  new  ADL  emerged 
almost  monthly.  Now  someone  proposing  a  new  language 
has  to  ask  themselves  (or  be  prepared  to  be  asked  by  their 
funding  agency)  “Does  what  you’re  proposing  have  any 
chance  of  unseating  UML?  What  tooling  will  you  provide 
with  it?” 

Nevertheless,  there  are  significant  opportunities  for 
new  contributions  in  software  architecture.  Some  of  the 
more  promising  areas  seem  to  be: 

•  Continuing  to  explore  formal  relationships  between 
architectural  design  decisions  and  quality  attributes. 
This  could  one  day  lead  to  a  practical  and 
sophisticated  automated  architecture  design  assistant. 
In  addition,  it  could  enable  earlier  and  more  accurate 
predictions  of  the  value  a  system  would  deliver  to 
specific  types  of  users. 

•  Finding  the  right  language  in  which  to  represent 
architectures.  UML  2.0  was  a  marginal  improvement 
over  its  predecessor,  but  it  still  lacks  basic 
architectural  concepts  such  as  “layer”  or  a  faithful 
notion  of  “connector”;  it  lacks  the  ability  to  analyze 
interactions  among  views;  it  too  easily  mixes  design 
concepts  with  implementation  directives;  and  it  lacks 
the  ability  to  make  strong  connections  to  code. 

•  Finding  ways  to  assure  conformance  between 
architecture  and  code.  Lack  of  conformance  dooms 
an  architecture  to  irrelevance  as  the  code  sets  out  on 
its  own  independent  trajectory.  We  should  work  to 
find  ways  to  establish  conformance  by  construction 
(via  generation,  refinement,  and  augmentation),  and 
by  extraction  (analyzing  an  artifact  statically  or 
dynamically  to  determine  its  architecture).  Early  work 
exists  in  both  of  these  approaches,  but  we  are  a  long 
way  from  reducing  conformance  to  a  solved  problem, 
especially  in  recovery/enforcement  of  runtime  views 
and  architectural  rules  that  go  beyond  structure. 

•  Re-thinking  our  approach  to  software  testing,  based 
on  software  architecture.  An  architecture  can  let  us 
generate  a  wide  variety  of  test  plans,  test  cases,  and 
other  test  artifacts.  For  code  that  originates  in  the 
architecture  (such  as  implementations  of  connections 
and  interaction  mechanisms)  automatic  testing  is 
possible.  It  should  be  possible  to  discriminate 
between  code  that  originates  in  the  architecture  (such 
as  that  which  implements  connections  and  interaction 
mechanisms)  and  code  that  is  non-architectural  in 
nature  (such  as  that  which  implements  hidden 
functionality  private  to  a  component).  We  should 
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have  different  eonfidenee  levels  in  arehiteetural 
versus  non-arehiteetural  eode,  and  we  should  be  able 
to  take  advantage  of  that  at  test  time.  And  it  should 
also  be  possible  to  generate  test  plans,  test  eases,  and 
other  test  artifaets  from  an  arehiteetural  deseription  of 
a  system.  A  strong  model  of  arehiteeture-based 
testing,  baeked  up  by  formal  reasoning  and  easy-to- 
use  tooling,  eould  have  a  major  eeonomie  impaet  on 
software  system  development. 

•  Organizing  architectural  knowledge  to  create 
reference  materials.  Mature  engineering  diseiplines 
are  eharaeterized  by  handbooks  and  other  referenee 
materials  that  provide  engineers  with  aeeess  to  the 
systematie  knowledge  of  the  field.  Cataloging 
arehiteetural  patterns  [17]  is  a  first  step  in  this 
direetion.  But  in  addition,  we  need  referenee  materials 
for  analysis  of  realized  arehiteetures  for  evaluation  of 
designs  to  prediet  properties  of  their  implementation. 
Grady  Booeh’s  handbook  on  software  arehiteeture 
“eodifying  the  arehiteeture  of  a  large  eolleetion  of 
interesting  software -intensive  systems,  presenting 
them  in  a  manner  that  exposes  their  essential  patterns 
and  that  permits  eomparisons  aeross  domains  and 
arehiteetural  styles,”  [15]  ean  provide  important 
exemplars,  but  engineers  also  need  referenee  material 
that  organizes  what  we  know  about  arehiteeture  into 
an  aeeessible,  dependable  body  of  knowledge. 

•  Developing  architectural  support  for  systems  that 
dynamically  adapt  to  changes  in  resources  and  each 
user’s  expectations  and  preferences.  As  eomputing 
beeomes  ubiquitous  and  integrated  in  everyday 
deviees,  both  base  resourees  sueh  as  bandwidth  and 
information  resourees  sueh  as  loeation-speeifie  data 
ehange  dynamieally.  Moreover,  eaeh  individual  user 
has  different  needs  that  ehange  with  time.  Developing 
arehiteetures  that  ean  dynamieally  antieipate  and  reaet 
to  these  ehanges  would  help  to  maximize  the  benefit 
eaeh  user  ean  obtain.  Aehieving  this  will  require  not 
only  adaptive  arehiteetures  but  also  eomponent 
speeifieations  that  refleet  variability  in  user  needs  as 
well  as  intrinsie  properties  of  the  eomponent. 

6,  The  golden  age 

It  will  be  interesting  to  see  how  these  ideas  fare  over 
the  next  ten  years  or  -  more  likely  -  to  see  what  ideas  now 
undreamed  of  will  have  emerged.  But  one  thing  seems 
elear.  The  last  deeade  and  a  half  has  seen  a  phenomenal 
growth  of  software  arehiteeture  as  a  diseipline.  It  started 
in  the  late  1980s  as  an  aeademie  idea,  based  on  venerable 
foundations,  that  was  aimed  at  understanding  and 
eodifying  system  deseriptions  observed  in  industrial 
praetiee.  From  there  it  has  grown  to  a  relatively  mature 


engineering  diseipline  eomplete  with  standard  and 
repeatable  praetiees,  a  rieh  eatalog  of  pre-paekaged  design 
solutions,  an  enormous  eommereial  market  supplying 
tools  and  eomponents,  and  a  universal  reeognition  that 
software  arehiteeture  is  an  indispensable  part  of  software 
system  development. 

A  “golden  age”  is  a  period  of  prosperity  and  exeellent 
aehievement  [6],  often  marked  by  numerous  advanees  that 
rapidly  move  the  teehnology  from  speeulative  to 
dependable.  Consider,  for  example,  the  golden  age  of 
aviation:  “Perhaps  the  most  exeiting  years  of  aviation 
history  span  the  period  from  the  end  of  World  War  I  to 
[the  United  States’]  entry  into  World  War  II.  This  period 
is  referred  to  as  golden  beeause  of  the  eountless  advanees 
in  aviation  teehnology  that  oeeurred,  the  many  expeditions 
undertaken,  and  the  numerous  reeords  set.”  [85]  The  last 
15  years  or  so  -  roughly  the  middle  four  stages  of  the 
Redwine-Riddle  model  -  truly  have  been  the  golden  age 
for  software  arehiteeture.  Like  the  golden  age  of  air  travel 
in  the  1930’s,  it  has  been  an  exeiting  time  of  diseovery, 
unfettered  imagination,  great  progress,  great  setbaeks,  and 
a  sense  of  the  possible. 

But  all  golden  ages  eome  to  a  elose,  and  as  software 
arehiteeture  moves  from  being  novel  to  being 
indispensable,  its  golden  age  is  reeeding.  This  is  as  it 
should  be.  Beeause  software  arehiteeture,  like  air  travel 
after  its  golden  age,  is  entering  a  period  where  it  ean  be 
taken  for  granted.  We  rely  on  it,  we  eannot  imagine  our 
teehnologieal  eulture  without  it,  and  we  are  eompelled  to 
eontinually  refine  and  improve  it  beeause  it  is 
indispensable. 

The  end  of  a  golden  age  should  not  be  taken  to  mean 
that  the  time  for  researeh,  innovation,  and  improvement 
has  passed.  In  aviation,  enormous  aehievements  sueh  as 
jet  engines,  supersonie  flight,  pinpoint  navigation,  and 
spaee  travel  all  happened  well  after  its  golden  age  had 
passed.  So  it  will  be  with  software  arehiteeture.  The 
strong  foundations  laid  by  the  early  phases  of  software 
arehiteeture  maturation,  eoupled  with  ongoing  researeh  to 
make  new  ideas  praetieal,  will  enable  even  more 
breathtaking  system-building  eapabilities  in  the  future. 
For  us,  the  intriguing  question  is  this:  What  new  software 
engineering  teehnology  and  its  golden  age  will  the 
solidly-established  field  of  software  arehiteeture  help  to 
usher  in? 
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8,  Appendix:  Citation  Analysis 

To  analyze  the  growth  of  the  field,  we  analyzed 
citation  patterns  for  books  and  papers  with  “software 
architecture”  in  the  title.  We  obtained  the  results  of  a  full 
search  for  such  papers  in  the  CiteSeer  database  [67].  We 
consolidated  variant  citations  for  papers  and  ignored  self¬ 
citations,  yielding  a  sample  of  about  5500  citations  to 
about  750  books  and  papers.  At  the  2005  Working 
lEEE/lFlP  Conference  on  Software  Architecture 
(W1CSA5),  about  20%  of  the  papers  had  “software 
architecture”  in  their  titles.  If  this  ratio  holds  for  the 
literature  at  large,  then  these  750  represent  about  20%  of 
the  software  architecture  papers. 

This  table  lists  the  top  two  dozen  books  and  papers  in 
this  sample,  along  with  the  top  two  dozen  works  in  a 
similar  (but  unordered)  sample  from  2001.  The  table  is 
ordered  by  2005  rank,  with  membership  in  the  2001  set 
shown  in  the  second  column. 


2005 

rank 

2001 

set 

Pub 

year 

Topic 

area 

Authors 

1 

yes 

95 

book 

Shaw,  Garlan.  SA: 
Perspectives  on  an 

Emerging  Discipline[82] 

2 

yes 

96 

book 

Buschmann  et  al.  Pattern- 
Oriented  SA  vol  I  [17] 

3 

yes 

92 

survey, 

model 

Perry,  Wolf.  Foundations 
for  the  study  of  SA  [68] 

4 

yes 

93 

survey, 

model 

Garlan,  Shaw.  An 
introduction  to  SA  [34] 

5 

yes 

95 

ADL 

Shaw  et  al.  Abstractions 
for  SA  and  tools  to  support 
them  [80] 

6 

yes 

98 

book 

Bass,  Clements,  Kazman. 

SA  in  Practice  [12] 

7 

94 

formaliz 

ation 

Magee  et  al.  Specifying 
distributed  SAs  [54] 

8 

yes 

94 

specific 

domains 

Macedonia  et  al. 

NPSNET:  A  Network  SA 
for  Large  Scale  Virtual 
Environments  [53] 

9 

96 

formaliz 

ation 

Magee,  Kramer.  Dynamic 
structure  in  SAs  [55] 

10 

92 

formaliz 

ation 

Allen,  Garlan.  A  formal 
approach  to  SA  [3] 

2005 

rank 

2001 

set 

Pub 

year 

Topic 

area 

Authors 

11 

95 

formaliz 

ation 

Inverardi,  Wolf.  Formal 
specification  and  analysis 
ofSA  [43] 

12 

yes 

95 

survey, 

model 

Garlan,  Perry.  Intro  to  the 
Special  Issue  on  SA  [33] 

13 

98 

specific 

domain 

Decasper  et  al.  Router 
Plugins:  a  SA  for  next 
generation  routers  [24] 

14 

yes 

93 

formaliz 

ation 

Abowd,  Allen,  Garlan. 

Using  style  to  understand 
descriptions  of  SA  [1] 

15 

97 

survey, 

model 

Medvedovic,  Taylor.  A 
classification  and  compari¬ 
son  framework  for  SA 
description  languages  [57] 

16 

yes 

95 

formaliz 

ation 

Abowd,  Allen,  Garlan. 
Formalizing  style  to 
understand  descriptions  of 
SA  [2] 

17 

94 

analysis 

tech 

Kazman  et  al.  SAAM:  a 
method  for  analyzing  the 
properties  of  SAs  [46] 

18 

yes 

92 

specific 

domains 

Locke.  SA  for  hard  real¬ 
time  applications  [51] 

19 

98 

specific 

domain 

Frigo,  Johnson.  FFTW:  an 
adaptive  SA  for  the  FFT 
[27] 

20 

yes 

91 

specific 

domains 

Chiola:  GreatSPN  1.5  SA 
[19] 

21 

yes 

95 

book 

Walden,  Nerson.  Seamless 
Object-Oriented  SA  [94] 

22 

94 

formaliz 

ation 

Moriconi,  Qian. 

Correctness  and 
composition  of  SAs  [62] 

23 

yes 

94 

specific 

domains 

Chapman  et  al.  A  SA  for 
multidisciplinary 
applications  [18] 

24 

00 

book 

Schmidt  et  al.  Pattern- 
oriented  SA  vol  2  [72] 

25 

yes 

92 

survey, 

model 

Mettala,  Graham.  The 
domain-specific  SA 
program  [60] 

29 

yes 

94 

survey, 

model 

Shaw,  Garlan. 
Characteristics  of  higher- 
level  languages  for  SA 
[81] 

30 

yes 

96 

formaliz 

ation 

Le  Metayer.  SA  styles  as 
graph  grammars  [49] 

35 

yes 

95 

survey, 

model 

Shaw,  Garlan. 

Formulations  and 
formalisms  in  SA  [83] 

36 

yes 

90 

specific 

domains 

Leung  et  al.  A  SA  for 
Workstations  supporting 
multimedia  conferencing 
in  packet  switching 
Networks  [50] 

38 

yes 

97 

rev  eng 

Yeh,  Harris,  Chase. 
Manipulating  recovered 

SA  views  [97] 
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2005 

rank 

2001 

set 

Pub 

year 

Topic 

area 

Authors 

47 

yes 

97 

survey, 

model 

Garlan.  Research 
directions  in  SA  [28] 

54 

yes 

93 

specific 

domains 

Cremer  et  al.  The  SA  for 
scenario  control  in  the 

Iowa  driving  simulator 

1231 

92 

yes 

95 

specific 

domains 

Kruchten.  The  4-U  view 
model  of  software 
architecture  [48] 

125 

yes 

92 

specific 

domains 

Coglianese,  Goodwin, 
Kushner,  Domain  analysis 
for  the  avionics  domain 
[22] 
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